- 
                Notifications
    You must be signed in to change notification settings 
- Fork 421
Various router fixes and #2417 follow-ups #2575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various router fixes and #2417 follow-ups #2575
Conversation
2544d6b    to
    b51e86e      
    Compare
  
    | Put in draft while taking another look at the failing test. | 
b51e86e    to
    8d4490c      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to get a test for this, but LGTM.
| Feel free to squash the fixup. | 
8d4490c    to
    50c9dba      
    Compare
  
    | 
 Squashed without further changes for now. | 
50c9dba    to
    85da1a1      
    Compare
  
    | Codecov ReportAttention:  
 ❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@            Coverage Diff             @@
##             main    #2575      +/-   ##
==========================================
+ Coverage   88.98%   89.00%   +0.02%     
==========================================
  Files         113      113              
  Lines       86291    86897     +606     
  Branches    86291    86897     +606     
==========================================
+ Hits        76787    77345     +558     
- Misses       7267     7300      +33     
- Partials     2237     2252      +15     
 ☔ View full report in Codecov by Sentry. | 
dec0e12    to
    0373099      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is missing test coverage for the various fixes, which would be really nice to include given the possibility of regressions.
0373099    to
    15a18b8      
    Compare
  
    4a2d62a    to
    fcd9fca      
    Compare
  
    fcd9fca    to
    4478fbd      
    Compare
  
    2496db9    to
    f39790d      
    Compare
  
    d7ab0ef    to
    aa6a612      
    Compare
  
    | // Only add the hops in this route to our candidate set if either we are part of | ||
| // the first hop, we have a direct channel to the first hop, or the first hop is in | ||
| // the regular network graph. | ||
| our_node_id == first_hop_src_id || | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to get test coverage of this at some point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, unfortunately not sure if it will make it in this PR though, if we want to land it for 117.
Previously this calculation could overflow, leading to panicking in `debug`.
5a5f7d1    to
    98c9849      
    Compare
  
    | Rebased on main, fixed the  | 
| LGTM, feel free to squash, I think. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after squash
Previously, we would only consider route hints if we had a direct channel to the first node in the hint or if the first node in the hint was part of the public network graph. However, this left out the possiblity of us being part of the first hop, especially if our own node is not announced and part of the graph.
If we have a direct channel to a node generating an invoice with route hints, we'd previously happily add multiple candidates that all refer to the same channel. To keep our candidate set small and unify our tracking where possible, we now check if its `short_channel_id` is an `outbound_scid_alias` of any of our first hops and refrain from adding another candidate if it's the case.
.. as a follow-up from lightningdevkit#2417.
.. as a follow-up from lightningdevkit#2417.
Previously, if an overpaid path would fail immediately, we'd retry a `PartialFailure` with the full path amount, _including_ any overpayment. Here, we now subtract the succeeded paths' values from the net. value to exclude the overpaid amounts on retry.
dbad082    to
    be1088a      
    Compare
  
    | Squashed fixups and included following changes: > git diff-tree -U2 dbad0824 be1088ac
diff --git a/lightning/src/routing/router.rs b/lightning/src/routing/router.rs
index 4252cd40..193fe352 100644
--- a/lightning/src/routing/router.rs
+++ b/lightning/src/routing/router.rs
@@ -2143,7 +2143,6 @@ where L::Target: Logger {
                        .filter(|route| !route.0.is_empty())
                {
-                       let first_hop_in_route = &(route.0)[0];
-                       let first_hop_src_id = NodeId::from_pubkey(&first_hop_in_route.src_node_id);
-                       let have_hop_src_in_graph =
+                       let first_hop_src_id = NodeId::from_pubkey(&route.0.first().unwrap().src_node_id);
+                       let first_hop_src_is_reachable =
                                // Only add the hops in this route to our candidate set if either we are part of
                                // the first hop, we have a direct channel to the first hop, or the first hop is in
@@ -2152,5 +2151,5 @@ where L::Target: Logger {
                                first_hop_targets.get(&first_hop_src_id).is_some() ||
                                network_nodes.get(&first_hop_src_id).is_some();
-                       if have_hop_src_in_graph {
+                       if first_hop_src_is_reachable {
                                // We start building the path from reverse, i.e., from payee
                                // to the first RouteHintHop in the path. | 
Based on #2570.
When overpaying to meet
htlc_minimum_msat, we update the path value and recompute fees accordingly. However, so far we didn't account for the extra paid fees invalue_contribution_msat, which leads to it beingslightly off, potentially having us hit a debug assertion when later checking the route's total value matches
already_collected_value_msat. Here, we therefore add the extra fees tovalue_contribution_msat.Moreover, we switch a calculation updating the used liquidity to use
saturating_add, as it could potentially overflow and panic indebug.We also include a number of follow-ups for #2417.